Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
See info in area-owners.md if you want to be subscribed.

EventSource also only looks at the derived type's fields and methods. I remember it being an intentional decision, but this was back in 2014ish and I can't remember why it was intentional. There was some scenario it broke to include the base class fields/methods.

There was some scenario it broke to include the base class fields/methods.

I can think if the base and inherited classes define non-virtual same property.

    public class A { public int P1 { get; set; } }
    public class B : A { public new int P1 { get; set; } }

Thanks guys! EventSource requires every method to be annotated with [Event] or [NonEvent] so I could easily imagine including new methods would break the init logic for some pre-existing EventSource. I think that will be a fairly different scenario than this one. It is theoretically possible that someone wrote a DiagnosticSourceEventSource listener that will fail if more properties than expected are enumerated, but it seems unlikely:

• The typical pattern is to use anonymous types for DiagnosticListener arguments in which case there are no additional base class properties to enumerate
• ImplicitTransform is intended as a development time scenario when you don't know which properties you need, after which the tool author would switch to an explicit property list
• Anyone who wrote code that breaks in this scenario would probably also break if a library author added a new property to their type. It would be a very version brittle technique with no benefit I am aware of so I am speculating folks wouldn't be doing it.